<p>This rule raises an issue when an if-else statement or ternary operator uses a negated condition that could be inverted to improve readability.</p>
<h2>Why is this an issue?</h2>
<p>Negated conditions in if-else statements can make code harder to read and understand. When you see <code>if (!condition)</code>, your brain has to
process the negation, which adds cognitive load.</p>
<p>Positive conditions are generally easier to understand because they describe what <strong>is</strong> true rather than what <strong>is not</strong>
true. When you have both an if and else branch, you can usually invert the condition and swap the branches to make the code more readable.</p>
<p>For example, <code>if (!user.isActive)</code> requires you to think "if the user is NOT active", while <code>if (user.isActive)</code> is more
direct: "if the user is active".</p>
<p>This pattern is especially problematic with:</p>
<ul>
  <li> Boolean negation using the <code>!</code> operator </li>
  <li> Inequality comparisons like <code>!==</code> and <code>!=</code> </li>
  <li> Complex expressions where the negation makes the logic harder to follow </li>
</ul>
<p>The rule only flags cases where there’s an else clause because single if statements with negated conditions are sometimes the clearest way to
express "do something when this condition is false".</p>
<h3>What is the potential impact?</h3>
<p>While this issue doesn’t affect functionality, it impacts code maintainability and readability. Code with negated conditions takes longer to
understand, especially for developers who are:</p>
<ul>
  <li> New to the codebase </li>
  <li> Working under pressure </li>
  <li> Non-native English speakers </li>
  <li> Debugging complex logic </li>
</ul>
<p>Improved readability leads to fewer bugs, faster code reviews, and easier maintenance.</p>
<h3>How to fix?</h3>
<p>Invert the negated boolean condition and swap the if and else blocks.</p>
<h4>Non-compliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
if (!isValid) { // Noncompliant
  handleError();
} else {
  processData();
}
</pre>
<h4>Compliant code example</h4>
<pre data-diff-id="1" data-diff-type="compliant">
if (isValid) {
  processData();
} else {
  handleError();
}
</pre>
<h3>Documentation</h3>
<ul>
  <li> <a href="https://github.com/sindresorhus/eslint-plugin-unicorn#readme">eslint-plugin-unicorn</a> - Rule <a
  href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/HEAD/docs/rules/no-negated-condition.md">no-negated-condition</a> </li>
  <li> ESLint no-negated-condition rule - <a href="https://eslint.org/docs/latest/rules/no-negated-condition">The original ESLint rule that inspired
  this implementation</a> </li>
  <li> JavaScript Conditional Statements - <a
  href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#conditional_statements">MDN documentation on
  JavaScript conditional statements</a> </li>
</ul>
<h3>Standards</h3>
<ul>
  <li> Clean Code: Meaningful Names - <a href="https://www.oreilly.com/library/view/clean-code-a/9780136083238/">Principles for writing readable and
  maintainable code</a> </li>
</ul>
